The present invention relates generally to computer software and computer network applications. More specifically, it relates to client-server applications and the transfer and arrangement of configuration data among components or storage areas in a computer network.
A conventional computer network involves connecting a series of personal computers commonly referred to as clients, to one or more server computers. Client computers are generally self-sufficient and contain within their resident memory much of the information needed to run user applications and communicate with a network. This includes information about their own configuration with regard to software and hardware capabilities and requirements. A client computer typically access network servers for a variety of reasons, such as accessing network software applications, email, retrieving and storing information on a network database, or accessing the Internet. However, information specific to a particular client computer generally resides on that client computer. This information can include, for example, the memory specifications and bus types, additional processors, and other hardware specifications. Since client computers are relatively self-sufficient and store their own configuration information (as opposed to storing such data on a server), the task of managing configuration and user data in addition to end user application data on a client computer has become increasingly burdensome.
While it is possible to propagate minor upgrades or fixes to applications residing on a network server to the client computers, any significant upgrade or fix, or installation of a new application that effects every client requires that each client computer be accessed and updated individually by a network administrator. With the increasing number of computers being connected to networks, ranging in the tens of thousands in some enterprises, the burden of installing major revisions or upgrades to application software or to general configuration software has become expensive, inefficient, and time-consuming. In addition, because most client computers are self-sufficient, it is difficult for users using different client computers at different locations to maintain personal preferences regarding applications and configuration data. That is, even though a user can install personal preferences as defaults on their normally-used client computer, it is burdensome to replicate these defaults on other client computers without changing defaults on those computers.
As described above, in a conventional network configuration, the process of installing new software or new applications is a static process. In such a configuration, the configuration information for each client is defined on each client machine. Thus, the network administrator statically defines each configuration on each client. In a conventional computer network, configuration information for each particular subsystem or client is hardcoded in the particular client. Furthermore, with conventional network configurations using self-sufficient clients connected to network servers, application maintenance, such as installing major upgrades to software, where the upgrade requires access to a subsystem""s configuration, normally requires that the network be xe2x80x9cbrought downxe2x80x9d to perform the maintenance.
With conventional computer networks that have multiple clients and a server in which the server contains information, that is needed by a client for various reasons, in many cases all the data on the server needed by or relevant to the client is moved from the server to the client. This can typically involve moving large amounts of data, much of which may not be used or is not necessary for the client to operate. Transferring all the data to the client is inefficient and increases network traffic. In addition, the client must have sufficient memory and storage to store all information relating to that particular client from the server. For example, devices such as PDAs and smart cards which do not have large storage capacities cannot contain in resident memory all necessary information, including configuration information that might be relevant to that particular device.
Another component of many conventional enterprise-wide networks are directory and naming services. Such services are used to store configuration and mapping information relating to network users and hardware components. This information is needed by users and components in a network to perform certain functions that require network services. Some widely used directory services are DNS (Directory Name Service), AD (Active Directory) used in the Windows NT(copyright) environment, and NIS in the Unix environment. A newer and powerful directory service that uses more current technology is the Lightweight Directory Access Protocol or LDAP, which is being used more widely in enterprise networks for directory services. FIG. 1 is a block diagram depicting how a client accesses data in an LDAP directory service. A client computer 102 in an enterprise environment 104 has an LDAP access module or add-on 106. When client 102 needs to access an LDAP directory 108, it does so directly using module 106 shown by line 110.
LDAP directory 108 is essentially a software server having a database and a software daemon (not shown). The database segment, which contains all the configuration and related data can be described functionally as a table 112 having two columns. One column contains an attribute and the second column contains one or more actual values. The attribute can be of any data category, for example, representing a user name, a logon name, a department, or hardware identifier. One advantage of directory services is the flexibility it gives network administrators to store any type of data that may need to be accessed by users or components in the network. One or more values can be associated with an attribute. For example, an attribute representing user-specific settings can have several values associated with it all, those values residing in the same value entry, separated by some type of delimiter. The structure and organization of LDAP directory 108 is well known in the field of computer network administration.
The information stored in these existing directory services, referred to as legacy systems, would have to be accessible to client computers in an enterprise network. Thus, any type of configuration repository that addresses the problems discussed above regarding the management of application and configuration data in expanding networks would have to accommodate or have access to configuration data on legacy systems such as LDAP directory services. A configuration server capable of providing client computers with configuration and user-specific data in an efficient manner must be able to exchange data with existing directory services containing configuration data.
Therefore, it would be desirable to have a system which supports distributed management of client and user configurations by storing such configuration information at a central repository. This would allow a network administrator to manage subsystem configurations from the server, and to propagate all types of changes to applications from a server. Furthermore, it would be desirable to have the central repository access legacy systems for configuration data rapidly, with minimum overhead processing, and have it done transparent to the client computers.
According to the present invention, methods, data structures, and computer readable media are disclosed for communicating data between a configuration server schema and a network directory service. In one aspect of the invention, an extension to a directory service enabling a mapping between a directory service attribute and a configuration server property is described. A directory service entry includes multiple shadow attributes where each shadow attribute corresponds to a particular directory service attribute. The particular directory service attribute, in turn, has a corresponding property in the configuration server. The extension also includes a correspondence or path matching file that contains matches between directory service addresses and configuration server location identifier or paths.
In one embodiment, the extension includes a directory service meta directory that contains a list of types in the directory service and an attribute list including attributes available for each directory type. In another embodiment each shadow attribute includes a corresponding configuration server property and a configuration server location identifier or path. In yet another embodiment, each shadow attribute includes a class name associated with the corresponding configuration server property. In yet another embodiment, the configuration server is a Java system database server containing configuration data for multiple clients and network users, and the location identifier is a series of nodes where each nodes represents a category of information. In yet another embodiment, the directory service is the Lighweight Directory Access Protocol.
In another aspect of the present invention, a format for a shadow attribute in a network directory service able to communicate with a configuration database is described. The shadow attribute contains a field for holding a configuration database property which can store a property name used in the configuration database. The shadow attribute also contains a field for a configuration database path that can be used for traversing the configuration database. Also included is a marker associated with the shadow attribute to identify the attribute as a shadow attribute.
In one embodiment, the shadow attribute format includes a configuration database class name field for storing a class name associated with the value stored in the configuration database. In another embodiment, the location identifier is a series of nodes in a hierarchical structure. In yet another embodiment, the directory service is the Lighweight Directory Access Protocol and the configuration database is a Java system database.
In yet another aspect of the present invention, a method for sending configuration data from a network directory service to a configuration database is described. One or more regular directory service entries and their corresponding values are retrieved from the network directory service and are transmitted to the configuration database. A location and property name in the configuration database for each corresponding value is determined by querying a shadow entry in the directory service in the network directory service. The corresponding values are stored in the configuration database based on the location or path determined from the shadow entry in the directory service.
In one embodiment, a context in the network directory service from which to retrieve the one or more directory service entries and corresponding values is determined. In another embodiment, each regular directory service entry is distinguished from each shadow directory service entry. In another embodiment, the shadow directory service entry contains a path on the configuration database and a property name associated with the configuration to database.
In yet another aspect of the present invention, a method of retrieving data from an LDAP server and transmitting it to a Java-based configuration server is described. A location matching file is searched for a match between a high-level path in the Java-based configuration server and a particular LDAP address. A portion of the LDAP server is searched for one or more attributes using the particular LDAP address to determine which portion of the LDAP server should be searched. One or more values corresponding to the one or more attributes is retrieved. The values are transmitted to the Java-based configuration server so that the values are made available to client computers in a Java operating system environment.